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The  point  of  open  systems  acquisitions  is  to  ensure  that  we  obtain  the  most 
effective  weapon  systems  possible — systems  that  are  affordable,  accommodate 
changing  technology,  and  promote  multiple  sources  of  supply.  Establishing  a 
disciplined  systems  engineering  approach  is  essential  to  achieving  this  goal. 


The  open  system  approach  is  both  a 
technical  approach  to  systems  en¬ 
gineering  and  a  preferred  business 
strategy  that  is  becoming  widely  applied 
by  commercial  manufacturers  of  large 
complex  systems.  It  has  the  attention  of 
Department  of  Defense  (DoD)  managers, 
who  have  mandated  its  use  by  DoD  sys¬ 
tems  developers.  Why?  Because  without 
such  a  change  in  system  development 
practice,  DoD  risks  being  unable  to  afford 
to  maintain  continued  superior  combat 
capability. 

Today,  legacy  weapons  systems  con¬ 
tinue  to  be  developed  with  their  own  often- 
unique  and  frequently  closed  infrastruc¬ 
tures,  making  upgrading  or  modifying 
them  over  their  expected  lifetimes  (20  to 
40  years)  both  problematic  and  expensive. 
Also,  reduced  procurement  budgets  and 
increased  dominance  of  commercial  tech¬ 
nology  cause  acquisition  managers  to  rely 


increasingly  on  commercial  markets  for 
affordable  product  development  and 
support.  So,  as  DoD’s  role  shifts  from 
being  a  technology  producer  to  being  a 
technology  consumer,  it  relies  more  on 
commercial  products  whose  design  is  not 
controlled  by  DoD  and  whose  lifetimes 
are  much  shorter  and  more  volatile  than 
the  weapons  systems  they  support  (e.g., 
years  vs.  decades).  As  a  result,  acquisition 
managers  risk  relying  on  unique  products 
provided  by  a  single  supplier  at  high  non¬ 
competitive  prices  and  with  little  oppor¬ 
tunity  for  technology  insertion  by  other 
suppliers. 

Here  we  discuss  the  need  for  a  rigor¬ 
ous  systems  engineering  process  that 
incorporates  open  systems  concepts  and 
principles — where  resulting  system 
designs  more  readily  accommodate 
changing  technology  to  achieve  cost, 
schedule,  and  performance  benefits  by 


One  Quality  inspected 


20000103  021 


Acquisition  Review  Quarterly — Winter  1999 


promoting  multiple  sources  of  supply  and 
technology  insertion. 

The  Need  for  an  Open 
Systems  Design  Approach 


An  open  systems  design  approach  can 
allow  a  weapon  system  program  office  to 
achieve  and  maintain  combat  superiority 
in  today’s  challenging  acquisition  environ¬ 
ment.  This  approach  focuses  the  design 
process  on  lowering  the  entire  life-cycle 
costs  (LCCs)  of  weapon  systems — in  contrast 
to  current  practice,  in  which  a  dispropor¬ 
tionate  focus  is  placed  on  the  short-term 
goal  of  having  the  lowest  development 
costs.  Figure  1  illustrates  that  well  over 
half  of  total  LCCs  are  incurred  post-IOC 
(initial  operational  capability)  during  the 
service  lifetime  (Defense  Systems  Man¬ 
agement  College,  1990).  The  ability  of  the 
open  systems  design  approach  to  improve 
life-cycle  supportability  is  becoming  an 
even  more  important  issue  as  DoD  limits 
the  number  of  new  weapon  systems 
procurements  and  extends  the  life  of  the 
systems  currently  fielded. 

It  seems  clear  that  DoD  managers 
should  concentrate  on  doing  things  in  sys¬ 
tems  engineering  and  development  that 
will  decrease  costs  during  production  and 
especially  during  the  operations  and  sup¬ 
port  (O&S)  phase.  An  open  systems 
approach,  basing  the  weapon  system’s 
design  on  open,  commercially  supported 
interface  standards  with  the  prospects  of 
a  large  supplier  and  customer  base, 
focuses  the  systems  engineering  process 
on  developing  system  designs  that  con¬ 
sider  life-cycle  support  requirements  up 
front  and  that  support  system  evolution 
throughout  the  system’s  life. 


An  open  systems  approach  also  miti¬ 
gates  the  increased  risks  of  obsolescence 
due  to  shortened  technology  cycle  time. 
Obsolescence  risks  are  significant  because 
technology  cycle  time,  sometimes  on  the 
order  of  months,  far  outpaces  weapon  sys¬ 
tem  development  cycle  time,  typically  8 
to  15  years.  By  the  time  a  system  is  fielded, 
supporting  technologies  are  often  out¬ 
dated — the  U.S.  military  cannot  afford  to 
be  three  or  four  technological  generations 
behind  what  is  available  on  the  commer¬ 
cial  market.  Open  systems  designs,  using 
commercially  supported  interface  stan¬ 
dards  that  permit  upgrade  at  a  relatively 
low  cost,  specifically  address  issues  of 
affordability  and  supportability  associated 
with  long-lived  systems  by  facilitating 
evolutionary  upgrade  with  new  technol¬ 
ogy.  Generally,  this  results  in  superior 
combat  capability  over  the  total  system 
life  cycle,  usually  at  a  lower  cost  to  the 
government. 

Another  reason  that  open  systems  have 
become  so  attractive  is  that  DoD  is  no 
longer  the  dominant  force  in  the  market¬ 
place  and  DoD’s  procurement  budget  has 
been  drastically  reduced.  DoD  no  longer 
has  the  luxury  of  technology  dominance, 
funded  by  seemingly  unlimited  budgets. 
In  prior  decades,  DoD  requirements  drove 
development  of  new  products  and  new 
technology.  In  today’s  environment  the 
opposite  is  true;  commercial  demand 
drives  product  and  technology  develop¬ 
ment.  However,  DoD  can  now  take 
advantage  of  commercial  innovation, 
research,  and  development  to  drive  down 
its  cost  of  developing,  acquiring,  and 
maintaining  weapon  systems,  leveraging 
the  commercial  investment  to  make  the 
most  of  available  and  shrinking  defense 
funds.  An  open  systems  approach,  using 
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open  interfaces  supported  by  commercial 
and  nondevelopmental  components,  can 
substantially  facilitate  this  leveraging. 

The  bottom-line  issue  is  not  only  cost: 
the  lives  of  our  servicemen  may  depend 
on  shortened  technology  insertion  cycle 
times.  In  a  global  market,  everyone, 
including  our  potential  adversaries,  will 
gain  increasing  access  to  the  same  com¬ 
mercial  technology  base.  The  military 
advantage  goes  to  the  nation  that  has  the 
best  cycle  time  to  capture  the  very  best 
commercially  available  technologies, 
incorporate  them  in  weapon  systems,  and 
get  them  fielded  first.  Moreover,  since 
coalition  operations  with  our  allies  place 
a  high  premium  on  interoperability,  it 
is  essential  that  our  systems  be  compat¬ 
ible  and  capable  of  being  sustained 
through  a  common  logistics  support  struc¬ 
ture.  Open  systems  specifications  and 


standards  promote  standard  interfaces  and 
interoperability  with  our  friends  and  allies. 

Each  of  these  many  issues  will  continue 
to  substantively  challenge  past  DoD 
acquisition  practices  throughout  the  fore¬ 
seeable  future.  As  a  result,  DoD  finds  itself 
with  few  alternatives  but  to  drastically 
alter  the  way  it  develops,  produces,  and 
supports  its  weapon  systems.  It  is  neither 
economically  nor  technologically  feasible 
to  continue  traditional  closed  design 
approaches.  DoD  is  increasingly  com¬ 
pelled  to  move  toward  a  more  open 
weapon  systems  design  alternative. 

Open  Systems  Design  Concepts 

Simply  put,  the  concept  of  open  sys¬ 
tems  is  a  commonsense  approach  that  has 
substantial  promise  as  a  way  to  meet 
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DoD’s  continuing  need  to  support  systems 
over  increasingly  long  life  cycles  in  an 
environment  of  decreasing  resources.  At 
a  time  when  the  development  of  a  complex 
system  can  span  several  generations  of  the 
faster  moving  technologies,  open  system 
architectures  offer  the  tantalizing  prospect 
of  facilitating  performance  upgrades  at 

affordable  costs 
for  the  lifecycle 
of  the  system. 
The  potential 
and  practice  of 
open  systems 
design  as  an 
emerging  topic 
within  the  sys¬ 
tems  engineer¬ 
ing  discipline 
has  now  been 
with  us  for  sev¬ 
eral  years.  In  addition,  the  use  of  open  sys¬ 
tems  has  received  the  attention  and  sup¬ 
port  of  the  highest  levels  of  DoD.  In  1996, 
DoD  issued  a  revised  directive  DoD 
5000.2-R,  which  instructs  program  man¬ 
agers  to  employ  open  systems  as  a  design 
consideration  in  defense  systems  engi¬ 
neering  (DoD,  1998)  This  directive  was 
subsequently  revised  and  stengthened 
with  Change  3  in  March  1998.  The  sys¬ 
tems  engineering  process,  with  specific 
reference  to  the  consideration  of  open  sys¬ 
tems  designs,  is  integral  to  achieving  the 
benefits  of  open  systems  designs. 

While  there  are  many  definitions  of 
open  systems,  most  have  a  few  character¬ 
istics  in  common  (Department  of  the 
Navy,  1993).  Open  systems  are  those  that 
can  be  supported  by  the  marketplace, 
rather  than  being  supported  by  a  single 
(or  limited)  set  of  suppliers,  due  to  the 
unique  aspects  of  the  design  chosen.  Open 


systems  architectures  are  achieved  by 
having  the  design  focus  on  commonly 
used  and  widely  supported  interface  stan¬ 
dards.  One  might  think  in  terms  of  the 
axle-wheel-tire  interfaces  employed  on 
commercial  cars.  By  adhering  to  common 
standards  at  the  interfaces,  the  consumer 
is  able  to  buy  tires  from  a  multitude  of 
suppliers,  rather  than  being  forced  to  buy 
from  a  single  source,  as  might  be  the  case 
if  the  interface  characteristics  were  unique 
to  a  single  supplier.  This  ensures  costs  and 
quality  that  are  controlled  by  the  forces  of 
competition  in  the  marketplace.  Further¬ 
more,  the  continued  support  of  the  sys¬ 
tem  is  not  subject  to  the  risks  associated 
with  having  a  single  supplier  go  out  of 
business  or  cease  supporting  the  standard. 
As  the  technologies  associated  with  tires 
change  with  time,  the  customer  can  con¬ 
tinue  to  upgrade  and  support  his  vehicle 
with  tires  that  are  built  to  the  accepted 
industry  standard  (e.g.,  from  conventional 
sidewall  bias-ply  technology  tires  to  steel- 
belted  radial -ply  technology  tires). 

But  despite  all  the  high-level  attention 
on  open  systems,  DoD  program  manag¬ 
ers  must  exercise  some  care  and  judgment 
in  their  application  of  the  open  systems 
approach.  It  does  not  represent  a  new 
approach  that  replaces  and  makes  obso¬ 
lete  previous  approaches  to  engineering 
complex  systems.  Moreover,  managers 
should  not  simply  implement  an  open 
standard  without  careful  consideration  of 
where  (in  the  system  hierarchy)  it  makes 
sense  to  impose  standards,  nor  should 
they  simply  grasp  for  a  commercial  item 
(Cl)  solution,  whether  or  not  the  solu¬ 
tion  leads  to  the  benefits  of  open  systems 
architectures.  Such  actions  may  encour¬ 
age  program  managers  to  declare  that  they 
are  achieving  open  systems  attributes, 
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whether  or  not  the  system  design  is  well 
thought  out  to  take  full  advantage  of  the 
benefits  that  the  open  systems  approach 
offers.  This  may  give  the  appearance  of 
achieving  open  systems  architectures  but, 
in  fact,  such  short-sighted  decisions  work 
against  the  long-term  viability  of  the  sys¬ 
tem.  The  open  system  concept  does  not 
replace  the  need  for  following  a  rigorous 
systems  engineering  process  but,  in  fact, 
requires  more  rigor  to  ensure  that  open 
systems  benefits  are  achieved. 

Open  Systems  Applied  Within 
the  Systems  Engineering  Process 

Systems  engineering  is  fundamentally 
a  problem-solving  process  that  translates 
needs  and  requirements  as  inputs  into 
designs  and  products  as  outputs.  The  sys¬ 
tems  engineering  process  typically  starts 
with  problem  definition  as  requirements 
are  analyzed.  Alternative  solutions  or  sys¬ 
tem  architectures  are  developed,  usually 
initially  through  techniques  such  as  func¬ 
tional  analysis  and  data  flow  analysis. 
Alternative  physical  designs  are  then 
developed  to  satisfy  the  functional  or  data 
flows.  Trade  studies  and  risk  analyses  are 
applied  to  select  a  preferred  design  solu¬ 
tion,  and  that  solution  is  verified  against 
the  original  requirements. 

This  process,  properly  applied,  results 
in  a  flow-down  of  requirements  from  the 
system  level  to  the  items  below  system 
level.  As  these  requirements  flow  down, 
the  design  requirements  for  the  items 
below  system  level  are  defined.  Once 
these  lower  level  design  requirements 
are  made  final,  the  design  process  pro¬ 
ceeds  to  completion.  The  result  is  a 
design  that  associates  physical  entities 
with  the  functions  the  system  must  per¬ 
form,  and  is  consistent  with  the  levels  of 


performance  required  and  with  the 
interfaces  specified. 

This  process,  applied  without  con¬ 
straints,  will  lead  to  the  design  of  a  sys¬ 
tem  in  which  every  item  is  optimized  to 
the  requirements  in  terms  of  function,  per¬ 
formance,  and  interface.  Too  often,  the 
results  in  DoD  have  been  systems  that  are 
unique  in  their 

designs,  that  , , ,  , ,  ,  , , 

perform  their  ir^ js 
missions  quite  a  problem  sddrg 
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require  unique  labesneedsand 
equipment  and  5  requremrfe  as 
parts  to  support  irfauls  irin designs 
them,  and  that  and  prodLds  as 
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ported  only  by  a 

limited  set  of  suppliers.  This  has  histori¬ 
cally  been  a  prescription  for  closed  sys¬ 
tems  that  are  both  difficult  and  costly  to 


inputs  into  designs 
arid  pmrtrtt  as 


support. 

The  challenge  in  DoD  is  to  design  sys¬ 
tems  to  take  advantage  of  open  systems 
concepts  where  that  makes  sense,  while 
continuing  to  meet  the  needs  and  require¬ 
ments  of  operational  forces.  The  solution 
is  not  to  suddenly  abandon  good  systems 
engineering  and  simply  impose  standard 
interfaces  at  some  point  in  the  system. 
Neither  is  the  answer  likely  to  be  found  in 
indiscriminately  importing  Cl  solutions 
into  the  system  architecture.  Rather,  the 
solution  is  to  perform  good  systems  engi¬ 
neering  while,  as  DoD  dictates,  employ¬ 
ing  open  systems  as  a  design  consideration 
from  the  outset.  The  challenge,  then,  is  to 
integrate  systems  engineering  and  open 
systems  design. 

To  this  end,  the  use  of  architectures  in 


DoD  has  become  a  preferred  management 
approach  for  implementing  an  open 
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systems  approach  (Under  Secretary  of 
Defense,  1996).  DoD  has  implemented 
this  concept  by  defining  an  interrelated  set 
of  architectures:  operational,  system,  and 
technical  (Figure  2).  Basically,  the  opera¬ 
tional  architecture  specifies  the  user 
requirements,  which  are  used  as  inputs  to 
the  systems  engineering  process  to  even¬ 
tually  build  the  weapon  system.  The  tech¬ 
nical  architecture  and  product  lines  con¬ 
strain  the  system’s  design  during  the 
system  engineering  process.  The  system 
architecture  emerges  as  an  output  and  is 
constmcted  to  satisfy  operational  architec¬ 
ture  requirements  within  the  rules  and 
standards  defined  in  the  technical  archi¬ 
tecture.  Technical  architectures  are  par¬ 
ticularly  important  to  the  systems  engi¬ 
neering  process  because  they  provide  the 
building  codes  for  implementing  systems 


upon  which  engineering  specifications  are 
based,  common  building  blocks  are  built, 
and  product  lines  are  developed.  Note  that 
while  each  of  these  architectures  by  them¬ 
selves  builds  nothing,  together  they  pro¬ 
vide  a  management  tool  that  facilitates 
evolutionary  acquisition  by  supporting 
insertion  of  new  technology,  component 
reuse,  improved  weapon  systems  inter¬ 
operability,  and  the  accommodation  of 
evolving  user  requirements. 

Who  chooses  the  technical  architec¬ 
ture?  Does  the  government  choose  the 
architecture,  does  industry  choose  the 
architecture,  or  is  the  architecture  chosen 
in  concert?  The  government  may  specify 
key  performance  attributes  of  system  build¬ 
ing  blocks  including  internal  interface  stan¬ 
dards.  But  doing  so  without  adequate  input 
from  industry  stifles  innovation,  limits 
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performance,  and  increases  cost  by  at¬ 
tempting  to  substitute  our  wisdom  for 
that  of  the  designer.  If,  on  the  other 
hand,  we  provide  no  guidance,  we  may 
encourage  development  of  proprietary 
architectures,  interfaces,  and  compo¬ 
nents.  That  would  leave  DoD  in  a  posi¬ 
tion  where  it  must  maintain  and  modify 
a  unique  product  with  a  single  supplier 
at  a  high,  noncompetitive  price.  Each 
program  must  choose  a  path  between 
these  two  extremes.  A  desirable  situation 
is  for  consensus  among  potential  prime 
contractors  and  their  key  suppliers  on 
application  of  widely  accepted  standards. 

Using  an  open  systems  approach  to  the 
systems  engineering  process  helps  achieve 
an  integrated  design  solution  that  is  resil¬ 
ient  to  changes  in  technology  throughout 
the  life  of  the  system.  Open  systems 


engineering  achieves  this  resiliency  in  life- 
cycle  supportability  by  engineering  sys¬ 
tems  according  to  the  following  principles 
and  practices  (Figure  3): 

•  Identify  as  critical  the  interfaces  to  sub¬ 
systems  or  components  that  are  likely 
to  change  due  to  their  dependence  on 
rapidly  evolving  technology,  are  likely 
to  have  increasing  requirements,  have 
high  replacement  frequency,  or  have 
high  costs.  Such  components  present 
both  the  highest  obsolescence  risks  and 
the  greatest  opportunity  for  future 
technology  insertion. 

•  Use  open  standards  for  these  critical 
interfaces  that  are  supported  by  the 
broader  community,  that  are  considerate 
of  life-cycle  support  requirements,  that 


FigLre  3.  Open  System  Analysis  far  Iribeg^ated  Desicp-i  Solution 
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permit  evolution  with  advances  in 
technology,  and  that  support 
technology  insertion. 

•  Use  a  modular  design  approach  com¬ 
bined  with  well-defined  standards- 
based  interfaces  among  modules  to  iso¬ 
late  the  effects  of  change  in  evolving 
systems,  serving  to  reduce  the  need  for 
redesign  as  the  system  is  upgraded. 

•  Identify  the  lowest  level  at  which  the 
government  maintains  control  over  the 
interface  standard,  and  anticipate  how 
this  level  may  change  over  time.  Below 
this  level  the  contractor  is  permitted  to 
use  its  best,  perhaps  proprietary,  prac¬ 
tices  to  improve  or  discriminate  its 
product  in  the  marketplace. 

•  Verify  all  performance  requirements 
and  reevaluate  their  stringency.  Real- 
location  of  requirements  as  necessary 
to  permit  the  wider  use  of  open 
standards  throughout  the  system. 

•  Implement  consistent  conformance 
management  practices  to  ensure  that 
products  procured  for  the  system  con¬ 
form  to  the  established  profile,  to  pre¬ 
vent  limitation  to  one  supplier  who 
might  unilaterally  extend  that  interface. 

The  key  to  achieving  the  benefits  of 
open  systems  designs  lies  in  making  open 
systems  an  integral  part  of  the  classic 
systems  engineering  process  and  in  apply¬ 
ing  open  systems  at  all  stages  of  the  prod¬ 
uct  life  cycle.  The  open  systems  approach 
to  design  will  never  replace  or  make 
obsolete  that  process — if  anything,  it 
demands  that  the  process  be  even  more 
rigorously  applied.  As  Figure  4  shows, 


each  of  the  major  aspects  of  the  systems 
engineering  process  must  include  consid¬ 
eration  of  open  systems  design  concepts 
and  principles. 

Requirements  analysis  must  empha¬ 
size  the  balancing  of  business  goals  (costs, 
common  use,  life-cycle  supportability, 
etc.)  with  technical  goals  (functionality, 
performance,  interfaces,  and  other  con¬ 
straints).  As  the  systems  engineering  pro¬ 
cess-  iterates,  the  requirements  analysis 
step  is  revisited  to  consider  cost-perfor¬ 
mance  tradeoffs  to  meet  most  performance 
objectives  while  achieving  as  large  as 
possible  reductions  in  life-cycle  costs.  The 
stringency  of  requirements  is  reevaluated 
to  consider  the  use  of  open  standards  for 
interfaces  as  performance  requirements 
are  balanced  (weighed)  against  business 
requirements.  To  do  this,  engineers  need 
to  be  better  trained  to  incorporate  life- 
cycle  cost  in  design  and  to  be  provided 
with  tools  that  allow  them  to  rapidly  assess 
life-cycle  cost  impacts.  Under  any  circum¬ 
stances,  users  need  systems  that  are 
supportable  and  affordable,  and  these 
requirements  demand  that  one  consider 
open  architectures  as  system  elements  are 
defined. 

Functional  analysis  and  allocation 

must  define  an  architecture  that  provides 
a  framework  for  identifying  interfaces 
critical  to  achieving  system  business  and 
technical  performance  goals.  Require¬ 
ments  should  be  allocated  with  a  view 
toward  achieving  functional  modularity. 
Functional  modularity  can  facilitate  physi¬ 
cal  modularity  and  the  use  of  open  inter¬ 
faces  to  support  system  evolution  goals. 
As  the  systems  engineering  process 
iterates,  this  step  is  revisited  to  allocate 
functionality,  to  modularize  those  compo¬ 
nents  or  subsystems  that  are  dependent  on 
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Process  Input 

Technical  architecture 
Product  lines 

Customer  needs,  objectives,  and  requirements 

-  Missions 

-  Measures  of  effectiveness 

-  Environments 

-  Constraints 
Technology  base 

Output  requirements  from  prior  development  effort 
Program  decision  requirements 

Requirements  applied  through  specifications  and  standards 


Requirements  Analysis  ^ — | 

•  Analyze  business  goals  I 

(costs,  common  use, 
scalability,  etc.)  and 
performance  goals. 

Requirements  Loop  ^  ^ 

Functional  Analysis  and  Allocation 

Define  an  architecture  that  identifies 

critical  interfaces 

Define  "level  of  openness" 

Apply  modularity 

Re-evaluate  "stringency"  of  requirements 
Consider  reallocation  of  performance 
or  business  requirements 


Design  Loop 


System  Analysis^ 
and  Control 
(Balance)  > 


Conformance  Management 

Tradeoff  studies 
Effectiveness  analyses 
Risk  management 
Configuration  management 
Interface  management 
Data  management 
Performance  measurement 

-  SEMS 

-  TPM 

-  Technical  reviews 


I _  Synthesis 

•  Make  implementation  decisions  based  on  market  research 

,Ve  ification  •  Prototype  to  delay  implementation  decisions 

\  Loop  •  Standardize  on  interfaces,  not  products 

>v  •  Build  strategic  supplier  relationships  with  vendors 

•  Develop  relationship  with  standards  community 


Related  Terms 

Customer  -  Organizations  responsible  for  primary 
functions 

Primary  functions  =  Development,  manufacturing, 
verification,  deployment,  operations,  support, 
training,  disposal 

System  elements  =  Hardware,  software,  personnel, 
facilities,  data,  material,  services,  techniques 


Process  Output 

System  architecture 
Development  level  dependent 

-  Decision  data  base 

-  System/configuration  item 
architecture 

-  specifications  and  baselines 


Figure  4. 

and  the  Systens  EngpnBering  Process 
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rapidly  evolving  technology,  have  high 
replacement  frequency  or  are  high  cost, 
and  to  reallocate  performance  or  business 
requirements  as  necessary  to  allow  for  the 
use  of  open  interface  standards  during 
synthesis. 

Synthesis  and  design  should  continue 
the  search  for  alternative  system  architec¬ 
tures  that  will  satisfy  requirements.  To  be 
effective,  good  design  synthesis  demands 
an  iterative  approach  that  involves  revis¬ 
iting  the  functional  allocations  and  devel¬ 
oping  alternative  physical  solutions  until 
a  balanced  design  (in  terms  of  cost,  per¬ 
formance,  and  risk)  is  achieved.  Modu¬ 
larity  should  be 
used  in  system 
design  where 
interfaces  be¬ 
tween  modules 
are  based  on 
open,  widely 
supported  inter¬ 
face  standards. 
Modularity 
should  be  based 
on  well-defined 
interfaces  to 
isolate  compo¬ 
nents  that  are 
likely  to  change 
over  time  (e.g.,  those  dependent  on  rap¬ 
idly  evolving  technology  or  that  have  high 
replacement  frequency)  or  are  high  cost, 
since  these  components  present  the  high¬ 
est  obsolescence  risks  and  the  greatest 
opportunity  for  future  technology  inser¬ 
tion.  Well-defined  interfaces  are  used  to 
decouple  system  components  and  define 
firewalls  to  contain  evolution  of  lower 
level  component  upgrades  and  modifica¬ 
tions,  thereby  minimizing  future  redesign, 
and  possibly  retesting,  when  components 


are  upgraded.  In  addition,  physical  modu¬ 
larity  should  be  aligned  with  functional 
partitioning  to  facilitate  the  replacement 
of  specific  subsystems  and  components 
without  impacting  others. 

Design  iteration  should  sequentially 
reconsider  the  allocations  of  function  and 
performance  that  define  the  design 
requirements  for  each  system  component 
with  the  objective  of  achieving  user 
(customer)  requirements  within  an  opti¬ 
mal  open  systems  solution.  From  an  open 
systems  perspective,  if  this  sequential 
iteration  is  stopped  as  soon  as  the  first 
acceptable  technical  solution  is  achieved, 
there  are  two  probable  results:  either  the 
solution  will  be  shown  to  require  unique 
designs  that  require  new  development,  or 
an  open  solution,  if  imposed  at  this  point, 
will  likely  not  meet  all  the  requirements 
of  the  user.  However,  in  most  cases,  a  final 
design  can  almost  certainly  be  developed 
that  results  in  system  architectures  that  in¬ 
clude  some  items  that  are  open  and  other 
elements  that  are  not.  Although  open 
designs  are  the  objective,  it  is  neither  nec¬ 
essary  nor  in  some  cases  even  possible  that 
every  element  or  item  of  most  complex 
systems  be  totally  open. 

Systems  analysis  and  control  must 
include  conformance  management ,  incor¬ 
porating  both  implementation  and  appli¬ 
cations  conformance  testing.  The  selected 
conformance  approach  must  be  fully 
defined  and  documented  so  that  it  is 
understood  by  all  parties.  The  degree  to 
which  open  systems  benefits  can  be 
achieved  will  depend  largely  on  how  well 
the  product  design  conforms  to  selected 
standards.  Completely  defined  interface 
profiles  will  allow  vendors  to  build  stan- 
dards-based  components  and  allow  users 
to  design  systems  to  use  standards-based 


"Tobeeffediv^ 
gooddesigisyrthe- 
sis  demands  an 
iterative  approach 
that  inudves  revis¬ 
iting  the  functional 
allocations  and 
deuelcpi  ng  alterna¬ 
tive  physical  solu¬ 
tions  until  a  bal- 
anoed  desist 
(in  term  of  cost; 
pafcmanoE^  and 
risk)  is  adieued  " 
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components.  In  all  cases,  candidate  com¬ 
ponents  should  be  tested  against  detailed 
system  profiles  to  ensure  that  components 
conform  to  profiles. 

Open  System  Design  Challenges 

The  open  approach  to  system  design 
offers  considerable  benefits,  already  dis¬ 
cussed,  in  terms  of  life-cycle  support, 
affordability,  and  timely  technology  inser¬ 
tion.  The  approach  also  carries  with  it 
some  substantial  differences  in  the  way 
that  systems  will  be  managed  and  sup¬ 
ported.  Since  by  its  nature  open  systems 
designs  will  involve  increased  use  of  com¬ 
mercial  and  nondevelopmental  items  in 
systems  architectures,  the  government  will 
necessarily  have  to  plan  for  significant 
differences  in  the  way  systems  are  man¬ 
aged  from  a  technical  perspective.  These 
differences  cut  across  almost  every  aspect 
of  engineering  management,  and  while 
space  prohibits  an  exhaustive  treatment, 
examples  include  the  following: 

•  Standards-based  architectures  lessen 
the  degree  of  control  that  DoD  can 
expect  to  exert.  Changes,  fixes,  and 
updates  will  likely  be  under  the 
vendor’s  control.  This  can  have  a 
significant  impact  on  system  support. 

•  Standards-based  elements  of  the  archi¬ 
tecture  are  likely  to  be  faster  and 
cheaper  to  acquire  than  a  comparable 
developmental  item  but  may  take  more 
time  to  integrate  and  test. 

•  Standards  selection  is  risky.  Acquisi¬ 
tion  will  require  substantially  more 
knowledge  of  the  current  state  of  the 


art  and  the  marketplace  on  the  part  of 
the  government. 

•  Standards  evolve  with  time.  It  is  diffi¬ 
cult  to  project  the  extent  to  which  a 
given  standard  will  endure.  It’s  equally 
challenging  to  determine  when  to  move 
from  one  standard  to  the  next. 

•  Standards-based  architectures  tend  to 
change  the  focus  of  systems  engineer¬ 
ing  from  design  to  integration.  The 
challenge  is  to  achieve  performance 
requirements  without  detailed 
control  over  the  component  design 
specification. 

•  An  item,  once  integrated,  may  affect 
other  system  parameters.  Commercial 
and  nondevelopmental  items  make 
testing  an  ongoing  and  continuing 
activity  to  verify  that  items  can 
integrate  successfully  into  systems. 

•  The  use  of  commercial  and  nondevel¬ 
opmental  items  requires  that  support 
concepts  be  developed  early  in  the 
acquisition  cycle. 

While  this  is  hardly  an  exhaustive  list, 
it  makes  the  point  that  open  systems  engi¬ 
neering  introduces  new  issues  into  the 
management  of  the  technical  aspects  of 
programs.  There  are  many  potential  ben¬ 
efits,  but,  likewise,  there  are  challenges 
and  problems  that  the  manager  must  be 
alert  to  anticipate  and  overcome. 

Summary 


The  objective  of  open  systems  acquisi¬ 
tions  is  to  provide  the  warfighter  with  the 
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most  effective  weapon  systems  possible. 
An  open  systems  approach  to  systems 
engineering  facilitates  this  throughout 
the  life  of  the  system.  Open  systems 
designs  provide  an  opportunity  to  achieve 
affordable  designs  that  can  more  readily 
accommodate  changing  technology  while 
promoting  multiple  sources  of  supply; 
however,  to  achieve  good  open  systems 
designs  first  demands  that  a  disciplined 
systems  engineering  approach  be  taken  to 
define  the  appropriate  elements  in  the 
system  to  be  opened. 

Most  systems  will  not  be  completely 
open  in  their  architectures,  but  a  well- 
engineered  design  will  result  in  a  design 
strategy  that  takes  maximum  advantage  of 
the  benefits  available  from  opening  the 
design.  Associated  with  an  open  approach 
is  the  need  to  focus  on  and  manage  the 
interfaces  between  open  system  elements 


and  other  elements  of  the  system.  Choos¬ 
ing  well-known  and  accepted  industry 
standards  and  applying  them  in  a  con¬ 
trolled  manner  will  go  far  toward  achiev¬ 
ing  the  desired  results.  Overall,  the  sys¬ 
tem  architecture  resulting  from  a  system 
engineering  process  should  be  linked  to  a 
business  case  analysis.  Architecture  deci¬ 
sions  should  be  traceable  to  performance, 
life-cycle  cost,  schedule,  and  risk.  The 
alternatives  for  support,  maintenance,  and 
upgrade  should  be  evaluated. 

For  maximum  benefit,  an  open  systems 
approach  should  focus  on  planned  use  of 
designs  across  a  system  or  domain.  As 
designs  are  opened,  managers  must  be 
aware  of  the  fact  that  support  and  acquisi¬ 
tion  strategies  will  necessarily  be  affected. 
These  impacts  must  be  anticipated  and 
planned  for  from  the  outset  during  system 
design. 
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